Motivation

• The customer detail view exposed a mutating add_customer_user POST action while the view was protected only by the read permission payments.view_customer, allowing read-only staff to provision/link users to customers.
• Customer.users membership grants access to sensitive self-service data, so adding users must require a stronger write-level permission.
• The change aims to prevent privilege escalation by requiring an explicit write permission before performing the invite/link operation.

Description

• Require payments.change_customer before executing the add_customer_user mutation by adding a check_add_customer_user_permission guard in weblate_web/crm/views.py and calling it at the start of add_customer_user.
• Add a context flag can_add_customer_user in CustomerDetailView.get_context_data to expose whether the current user has the change permission.
• Hide the Add-user form in weblate_web/crm/templates/payments/customer_detail.html unless can_add_customer_user is true.
• Add two regression tests in weblate_web/crm/tests.py verifying that a read-only staff user (with only view_customer) does not see the form and receives HTTP 403 when POSTing the add action.

Testing

• Ran pytest -q weblate_web/crm/tests.py -k 'readonly_staff or adds_hosted_user' and the selected tests passed: 3 passed, 93 deselected.
• The hosted-user invite tests exercised the successful invite path and still pass under the new permission guard when executed with a user that has the required permissions.
• No other test suites were run as part of this change; the modification is intentionally minimal to restrict authorization for the new mutation.

Codex Task